home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 5451 / text0000.txt < prev   
Encoding:
Text File  |  1996-08-05  |  3.9 KB  |  125 lines
  1. Mathew Hendry schrieb in comp.sys.amiga.programmer ueber "Re:
  2. animation.datatype":
  3.  
  4. MH>: That would be hard in the extreme, thanks to the abyssmaly poor
  5. MH>: animation.datatype that you have to inherit from. That's why we need
  6. MH>: a new animation.datatype. It should be able to: Load-While-Playing
  7. MH>: (TM) ;-) Use CyberGFX. Scale, perhaps. Be mucho more flexible,
  8. MH>: generally.
  9.  
  10. MH>The same goes for other datatypes (sound, picture etc.). An extended
  11. MH>system which allowed the datatypes to work with streams (rather than
  12. MH>complete datasets) and more advanced hardware would make them much more
  13.  
  14. Yes thats true....
  15.  
  16. MH>down on memory usage substantially. If you were to extend it further,
  17. MH>simple processing features could be added.
  18.  
  19. Yes and all this should be modularized.
  20.  
  21. I wrote something on the AmigOS mailinglist about that.. Maybe it is of
  22. interest.... I hope its clearly enough to be understood.
  23.  
  24. It goes a little bit further... but maybe this is not too bad... I am just
  25. wondering, _how_ it could be implemented efficiently.
  26.  
  27. -------------------------------------------------------------------------
  28. From: Martin Steigerwald
  29. To: Martin Steigerwald
  30. Receive-Date: Montag, 11-MΣr-96  18:13:41
  31. Creation-Date: Montag, 11-MΣr-96  18:13:41
  32. Message-ID: 71272327@sunshine.stud.uni-frankfurt.de
  33. Date: Montag 11-MΣr-96  18:13:41
  34. References: 71272326@sunshine.stud.uni-frankfurt.de
  35. Subject: new datatypes scheme!?
  36. Folder: list.AmigOS
  37. UserFlags: Old WriteAccess ReadAccess ViewAccess Owner
  38. GlobalFlags: Exported
  39.  
  40.  
  41. Hi!
  42.  
  43. What about are more differenciated datatypes scheme for the new os... as
  44. follows!?
  45.  
  46. datatype
  47.     - load-smallest-element (codec)
  48.     - load-all
  49.     - save-smallest-element (codec)
  50.     - save-all
  51.     - view (gadget)
  52.     - operators
  53.       - e.g. convert text from one standard to another
  54.       - or: rotate an image... an such
  55.     - editors
  56.       - direct link to editing software or directly integrated editing
  57.         software for each type
  58.     - arexx interface type
  59.  
  60. This would add the following features:
  61.  
  62. - able to do progressive type loading (good for those html browser with
  63.   progressive image loading)
  64. - able to manipulate types contents in a modular
  65. - able to integrate application more smoothly in that scheme
  66.  
  67. Imaginge a texteditor:
  68. - it could use ascii-loaders and savers
  69. - it could have operators such as
  70.   - delete a line
  71.   - change a line
  72.   - reformat a block and such
  73. - and the main part is in the editor.subtype
  74.  
  75. You could use it to view text, but also to edit texts. And even better
  76. only viewing texts would mean that only loadtype and viewtype will be
  77. loaded, but not the operators and editor.subtype
  78.  
  79. Hmmm, I am getting a bit confused with the slang... is it a subtype, a
  80. datatype sub class or what...  :-)
  81.  
  82. A new prefs accessing scheme could be implemented this way...
  83.  
  84. - load (part of) tag based IFF PREFS file
  85. - save ....
  86. - change one part of the file
  87. - edit it
  88.   |
  89.   --general
  90.    |-- printer, serial, screenmode bla bla....
  91. - view contents...
  92. - arexx interface
  93.  
  94. An in SYS:Prefs only the starters of all this in global mode.
  95.  
  96. main()
  97. {    OpenLibrary("inputprefsedit.class",bla)
  98.     execute the edit function via a single call... (DoMethod?)
  99.     CloseLibrary(bla)
  100. }
  101.  
  102. thats it, for one prefs program... all is modular...
  103.  
  104. But could such a scheme be implemented without to much overhead???
  105.  
  106. ----------------------------------------------------------------------
  107.  
  108.  
  109. Let the sun shine... \__Mail| Usenet:   steigerw@stud.uni-frankfurt.de
  110. |_| _ |o _  _ Martin    \__ |                            WWW-Homepage:
  111. | |(/_||(_)_> Steigerwald  \| http://www.rz.uni-frankfurt.de/~steigerw
  112.  
  113. _Legal notice:_ Microsoft Network is prohibited from redistributing this
  114. work in any form, in whole or in part.
  115.  
  116. -----------------INTUINEWS------
  117.  
  118.  
  119. Let the sun shine... \__INet| Usenet:   steigerw@stud.uni-frankfurt.de
  120. |_| _ |o _  _ Martin    \__ |                            WWW-Homepage:
  121. | |(/_||(_)_> Steigerwald  \| http://www.rz.uni-frankfurt.de/~steigerw
  122.  
  123. Humans against fascism!!! --> Bytes against fascism!!!
  124.  
  125.